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1 BACKGROUND OF THE INVENTION 

2 
3 

4 1. Field of the Invention 

5 

6 The present invention relates in general to computer file systems, and more particularly 

7 to an extensible file access method for accessing a foreign file system from a data processing 

8 system with a native file system, said foreign file system and said native file system 

9 implementing different file system protocols. 
10 

11 
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2 2. Description of the Related Art 

3 

4 A file system comprises the logical structures and software function routines used to 

5 store, organize, and access information stored on a computer system's logical or physical 

6 storage media, such as a diskette, hard disk system, or optical storage. A variety of file systems 

7 have been developed to address various needs. For example, personal computer file systems 

8 comprise: File Allocation Table (FAT); Virtual FAT (VFAT); 32-Bit FAT (FAT32); New 

9 Technology File System (NTFS); and High Performance File System (HPFS). File systems for 

1 0 mid-range computers comprise: Unix File System (UFS), Network File System (NFS), and 

1 1 AS/400. Mainframe computer file system offerings comprise: Virtual Storage Access Method 
,,12 (VSAM ); Sequential Access Method (SAM); Partitioned Data Set (PDS); and Object Access 
M43 Method (OAM). File systems are not limited to these lists which are merely illustrative subsets 
'■■J 4 of the numerous variety of file systems. 

p| 5 

■{16 The various computer architectures and computer operating systems may use different 

* 17 file systems, thus organizing and accessing the information in different ways. Generally, these 

s13 8 different file systems are incompatible, meaning that files created by one file system may not 

7 J^i9 be accessed by another file system.. A user may have a computer system supporting a 

020 particular file system, a native file system, and the user may wish to access and use information 

21 stored in a file system other than the native file system, a foreign file system. The user may 

22 need to access the foreign file system information for any of a number of motivations, such as 

23 to migrate the information to a replacement system, to archive the information, or to share the 

24 information among different systems. 
25 

26 Conventional systems have addressed this user need to access foreign file systems in a 

27 number of ways. The earliest conventional approach was to create a duplicate of the 

28 information and to convert the information in this duplicate from the native file system format 

29 to the foreign file system format. This approach is exemplified by patents such as U. S. Patent 



STL9-2000-0057US1 



4 



1 Number 5,537,592, "System and Method for Reading and Writing Disks Formatted for an 

2 Operating System Foreign to the Host Computer;" U. S. Patent Number 5,742,818, "Method 

3 and System of Converting Data from a Source File System to a Target File System;" Japan 

4 Patent Number 923 1 1 1 4A, "File System Conversion System;" and "Japan Patent Number 

5 6243020A, "File Conversion Device." U. S. Patent Number 5,537,592 is representative of this 

6 approach, and in particular teaches a set of processes and data structures that allow transfer of 

7 user specified files between differently formatted disks. The processes identify the file format 

8 of the source and destination disks, retrieve the source files in the source file format, store the 

9 source files in a common format in memory that allows the directory hierarchy of the source 

10 disk and destination disk to be maintained, translate the contents of text source file records to 

1 1 the record format of the destination file system if desired, create directories and headers if 

i42 necessary for the foreign disk for the transferred files, and store the files on the destination disk 

s :jj 3 in a host file format. The user can then access and modify the files in the host file format using 

H4 a host computer system. This approach is only a partial solution in that it only converts and 

r15 reformats the information, it does not convert the software functions. The native file system 

'136 can still only access information stored in the native file system format; it cannot access 

* 17 information stored in the foreign file system format, nor can it use the foreign file system 

ij| 8 software functions. 

C420 Another conventional solution is to install and support both file systems on the same 

21 computer system., effectively making the foreign file system an additional native file system. 

22 This solution is taught by U.S, Patent Number 5,363,487, "Method and System for Dynamic 

23 Volume Tracking in an Installable File System," which permits a single operating system to 

24 access a storage medium formatted in accordance with differing file systems. Generally, the 

25 operating system identifies which of a plurality of file system drivers is appropriate for reading 

26 a particular storage volume and, thereafter, associates the identified file system driver with the 

27 particular storage volume. Similarly, U. S. Patent Number 5,91 1,776, "Automatic Format 

28 Conversion System and Publishing Methodology for Multi-user Network," provides a set of 

29 multiple shadow file converters connected to a source file of an original document. Each 
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1 shadow file converter enables the transformation of the original source file format into a 

2 particular other specific type of file format. However, providing all the permutations of the 

3 different types of file systems ported to the different types of operating systems and computer 

4 hardware architectures is probably not commercially feasible. 
5 

6 A more robust conventional approach is to directly convert file system requests from 

7 one file system protocol to another. For example, a client system, having a native file system 

8 protocol, may issue a request in the client's native file system protocol to a server. However, 

9 the server uses a foreign file system protocol which is different form the client's native file 

10 system protocol A file system protocol converter translates the client's request from the 

1 1 client's native file system protocol to the server's foreign file system protocol. The file system 
g42 converter may also convert the server response by reformatting the response's information from 
j§3 the server's foreign file system format to the client's native file system format. This type of 
H 44 direct file system protocol conversion is taught by: U. S. Patent Number 5,21 8,697, "Method 
ri5 and System for Networking Computers Having Varying File Architectures;" U. S. Patent 

y 6 Number 5,752,005, "Foreign File System Establishing Method which Uses a Native File 

1)7 System Virtual Device Driver;" U. S. Patent Number 5,937,406, "File System Interface to a 

yi 8 Database;" U. S. Patent Number 5,864,853, "Portable File System Operable Under Various 

*f J 9 Computer Environments;" and U. S. Patent Number 4,956,809, "Method for Canonical 

Ct>0 Ordering of Binary Data for Portable Operating Systems." Foreign patents representative of 

21 this approach include: Japan Patent Number 10247 155 A, "File System Interface for Data 

22 Base;" Japan Patent Number 8137728A, "Portable File System and File Data Processing 

23 Method;" Japan Patent Number 7230396A, "Mutual Constitution System for Different Kinds 

24 of File System Forms;" and Japan Patent Number 10260877A, "Protocol Conversion System in 

25 Client Server System, Method Therefor and Recording Medium Programmed and Recorded 

26 with the Method." Publications of this approach include: "File Interface for Migrating 

27 Applications to Enhanced Persistent Storage Platforms," IBM Technical Disclosure Bulletin, 

28 June 1992, p. 182-183; "AS/400 OS/2 PC Support Shared Folders," id., Dec. 1989, p. 202- 

29 205; "Method to Manage the Mapping of Logical to Physical Record " id., Dec. 1 995, p. 26 1 - 
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1 262; "Implicit Mapping of File Data,** id., April 1995, p. 523-524; and "OS/2 Logical File 

2 System,'* id., May. 1992, p. 370-371. Although this approach is a significant improvement 

3 over merely converting the information format, it still suffers from the disadvantage of even 

4 more permutations, where the permutations for each converter for a different pair of source and 

5 target file systems ported to the different types of operating systems and computer hardware 

6 architectures is also probably not commercially feasible. 
7 

8 Thus, there is a clearly felt need for a method, system and computer program product 

9 for providing an improved extensible file access method for accessing a foreign file system 

10 from a data processing system with a native file system, said foreign file system and said native 

11 file system implementing different file system protocols. 
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1 SUMMARY OF THE INVENTION 

2 

3 The present invention comprises an extensible file access method for accessing a first 

4 foreign file system from a data processing system with a first native file system, said first 

5 foreign file system and said first native file system implementing different file system 

6 protocols. 
7 

8 In accordance with an aspect of a preferred embodiment of the present invention, an 

9 extensible file access method for accessing a foreign file system from a data processing system 

10 with a native file system, said foreign file system and said native file system implementing 

1 1 different file system protocols, comprises the steps of: 

,42 issuing a request according to the native file system protocol for data stored in the 

^13 foreign file system; 

y 4 translating the native file system request to an intermediate programming interface, 

i4 5 wherein the intermediate programming interface is different from both the native file system 

■if 6 protocol and the foreign file system protocol; 

* 17 translating the intermediate file system request to the foreign file system protocol; and 
'{n 8 returning to the data processing system a response from the foreign file system 

H 9 responsive to the translated request. 

CEO 

* 21 In accordance with another aspect of a preferred embodiment of the present invention, 

22 the extensible file access method is extended to support a second foreign file system by 

23 determining the second foreign file system protocol and by providing a translation from the 

24 intermediate programming interface to the second foreign file system protocol. 
25 

26 In accordance with another aspect of a preferred embodiment of the present invention, 

27 the extensible file access method is extended to support a second native file system by 

28 determining the native file system protocol and by providing a translation from the second 

29 native file system protocol to the intermediate programming interface. 
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1 In accordance with another aspect of a preferred embodiment of the present invention, 

2 the intermediate programming interface comprises a set of generic access functions common to 

3 the native file system protocol and the foreign file system protocol, and comprises a set of file 

4 system specific functions which are not common to the file system protocols. 
5 

6 In accordance with another aspect of a preferred embodiment of the present invention, 

7 the set of generic access functions common to the native file system protocol and the foreign 

8 file system protocol are translated from the native file system protocol to the intermediate 

9 programming interface which is then translated to the foreign file system protocol, and the set 

10 of file system specific functions which are not common to the file system protocols are not 

1 1 translated from the native file system protocol to the intermediate programming interface. 
A2 

jjji 3 In accordance with another aspect of a preferred embodiment of the present invention, 

S3 4 the set of file system specific functions which are not common to the file system protocols 

=4 5 further comprises a set of extended native file system functions which have no equivalent 

5 :j6 function in the foreign file system protocol, 
s 17 

[ti8 In accordance with another aspect of a preferred embodiment of the present invention, 

jr:l 9 the set of extended native file system functions causes a predetermined response to be sent to 

1320 the data processing system. 

22 In accordance with another aspect of a preferred embodiment of the present invention, 

23 the set of file system specific functions which are not common to the file system protocols 

24 further comprises and a set of extended foreign file system functions which have no equivalent 

25 function in the native file system protocol. 
26 

27 In accordance with another aspect of a preferred embodiment of the present invention, 

28 the set of extended foreign file system functions are passed through to the foreign file system in 

29 an untranslated form. 
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1 A preferred embodiment of the present invention has the advantage of providing a 

2 method for integrating existing applications which use a native file system with back-end data 

3 management systems which use a separate foreign file system. 
4 

5 A preferred embodiment of the present invention has the advantage of allowing an 

6 application written for the native file system to read and write data to a back-end application or 

7 back-end data store without requiring file system modifications of that application. 
8 

9 A preferred embodiment of the present invention has the advantage of allowing the 

10 native file system application to create, view and manipulate the meta-data for the back-end 

1 1 application from the native file system application. 

d 2 

Jj 3 A preferred embodiment of the present invention has the advantage of allowing the 

SI 4 foreign file system application to appear as if it is written to the native file system. 

II 5 

-;f j 6 A preferred embodiment of the present invention has the advantage of allowing the 

a 17 native file system application to access the foreign file system as if it is a native file system. 
B 8 

j"J19 A preferred embodiment of the present invention has the advantage of reducing the 

1*320 complexity of supporting an additional native file system. 

22 A preferred embodiment of the present invention has the advantage of reducing the 

23 complexity of supporting an additional foreign file system. 
24 

25 A preferred embodiment of the present invention has the advantage of reducing the 

26 complexity of translating from multiple native file system protocols to multiple foreign file 

27 system protocols. 
28 

29 A preferred embodiment of the present invention has the advantage of allowing the 
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1 native file system application by use of the virtual file system to seamlessly access statically 

2 stored files (such as File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), 

3 hierarchical data base files, relational data base files, and object oriented database files) and 

4 dynamically constructed files (such as Information Management System (IMS) transactions or 

5 Customer Information Control System (CICS) transactions). 
6 

7 A preferred embodiment of the present invention has the advantage of providing a 

8 consistent and potentially standard method for accessing back-end storage systems. 
9 

10 A preferred embodiment of the present invention has the advantage of providing a 

1 1 unified storage access model which allows native file system applications and the native 
g42 operating system to seamlessly import and export data to back-end server systems via the 

W3 virtual file system by presenting the back-end systems in a way as to be indistinguishable from 

SI 4 the local file system. 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 

3 For a more complete understanding of the present invention and the advantages thereof, 

4 reference is now made to the Description of the Preferred Embodiment in conjunction with the 

5 attached Drawings, in which: 
6 

7 Figure 1 is a block diagram of a distributed computer system which may be used in 

8 performing the method of an embodiment of the present invention, forming part of the 

9 apparatus of an embodiment of the present invention, and which may use the article of 

1 0 manufacture comprising a computer-readable storage medium having a computer program 

1 1 embodied in said medium which may cause the computer system to practice an embodiment of 
Jfi the present invention; 

l 3 

%J4 Figure 2 is a block diagram of an architecture of a preferred embodiment of the present 

invention; and 

16 

s; 17 Figures 3 and 4 are flowcharts illustrating the operations preferred in carrying out a 

III 8 preferred embodiment of the present invention. 
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1 DESCRIPTION OF THE PREFERRED EMBODIMENT 

2 

3 Referring first to Figure 1, there is depicted a graphical representation of a data 

4 processing system 8, which may be utilized to implement the present invention. As may be 

5 seen, data processing system 8 may include a plurality of networks, such as Local Area 

6 Networks (LAN) 10 and 32, each of which preferably includes a plurality of individual 

7 computers 12 and 30, respectively. Of course, those skilled in the art will appreciate that a 

8 plurality of Intelligent Work Stations (IWS) coupled to a host processor may be utilized for 

9 each such network. Each said network may also consist of a plurality of processors coupled via 

10 a communications medium, such as shared memory, shared storage, or an interconnection 

1 1 network. As is common in such data processing systems, each individual computer may be 
r|2 coupled to a storage device 14 and/or a printer/output device 16 and may be provided with a 
?$3 pointing device such as a mouse 17. 

if 4 

ip5 The data processing system 8 may also include multiple mainframe computers, such as 

fi 6 mainframe computer 18, which may be preferably coupled to LAN 10 by means of 

communications link 22. The mainframe computer 18 may also be coupled to a storage device 

111 8 20 which may serve as remote storage for LAN 10. Similarly, LAN 10 may be coupled via 

yJ9 communications link 24 through a sub-system control unit/communications controller 26 and 

:"$0 communications link 34 to a gateway server 28. The gateway server 28 is preferably an IWS 

2 1 which serves to link LAN 32 to LAN 10. 
22 

23 With respect to LAN 32 and LAN 10, a plurality of documents or resource objects may 

24 be stored within storage device 20 and controlled by mainframe computer 18, as resource 

25 manager or library service for the resource objects thus stored. Of course, those skilled in the 

26 art will appreciate that mainframe computer 18 may be located a great geographic distance 

27 from LAN 10 and similarly, LAN 10 may be located a substantial distance from LAN 32. For 

28 example, LAN 32 may be located in California while LAN 10 may be located within North 

29 Carolina and mainframe computer 18 may be located in New York. 
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1 Software program code which employs the present invention is typically stored in the 

2 memory of a storage device 14 of a stand alone workstation or LAN server from which a 

3 developer may access the code for distribution purposes, the software program code may be 

4 embodied on any of a variety of known media for use with a data processing system such as a 

5 diskette or CD-ROM or may be distributed to users from a memory of one computer system 

6 over a network of some type to other computer systems for use by users of such other systems. 

7 Such techniques and methods for embodying software code on media and/or distributing 

8 software code are well-known and will not be further discussed herein. 
9 

] 0 As will be appreciated upon reference to the foregoing, it is often desirable for a user 

1 1 working on a workstation 12 to be able to access information or files stored on host storage 

,12 device 20 on the host 1 8. Such files are usually stored on host storage device 20 in accordance 

yf 3 with a host file system protocol which is different from the workstation file system protocol 

^14 used to store files on the workstation 12. The present invention provides an extensible file 

f|5 access method and virtual file system which allows an application executing on the workstation 

'JJ6 12, having a native file system for files stored on the workstation 12, to access files stored on 

* 17 the host storage device 20, the host storage files being stored in a foreign file system 

jjf 8 implementing a different file system protocol from the workstation or native file system 

f|9 protocol. 
Q0 

21 Referring next to Figure 2, there is shown a block diagram of an architecture of a 

22 preferred embodiment of the present invention. The foreign file system 20 is accessed by 

23 issuing a request according to the native file system protocol 285 for data stored in the foreign 

24 file system 20; translating the native file system request to an intermediate programming 

25 interface 250, wherein the intermediate programming interface 250 is different from both the 

26 native file system protocol 285 and the foreign file system protocol (255, 260, or 265); 

27 translating the intermediate file system request to the foreign file system protocol; and 

28 returning to the data processing system a response 295 from the foreign file system responsive 

29 to the translated request. Multiple foreign file systems 235 and 240 may be supported by 
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1 determining a second foreign file system protocol and by providing a translation from the 

2 intermediate programming interface to the second foreign file system protocol. Also, multiple 

3 native file systems may be supported by determining a second native file system protocol and 

4 by providing a translation from the second native file system protocol to the intermediate 

5 programming interface. 
6 

7 The intermediate programming interface comprises a set of generic access functions 

8 common to the native file system protocol and the foreign file system protocol and a set of file 

9 system specific functions which are not common to the file system protocols. The set of 

10 generic access functions common to the native file system protocol and the foreign file system 

1 1 protocol are translated from the native file system protocol to the intermediate programming 
42 interface which is then translated to the foreign file system protocol, and the set of file system 
'j?3 specific functions which are not common to the file system protocols are not translated from 
'44 the native file system protocol to the intermediate programming interface which is then 

fl5 translated to the foreign file system protocol. Existing applications which use a native file 

s "y 6 system may be more easily integrated with back-end data management systems which use a 

« 17 separate foreign file system without requiring file system modifications of the existing 

III 8 application. A foreign file system application may appear as if it is written to the native file 

"f j 9 system, and a native file system application may access the foreign file system as if it is a 

GEO native file system. A dynamic virtual file system may be constructed to support a consistent 

21 standard interface to seamlessly access statically stored files and dynamically constructed files. 

22 

23 Sash 200 is a replacement for a conventional Common Internet File System (CEFS) 

24 server. It consists of a Server Message Block (SMB) server 210 which interfaces to a client 

25 215, and one or more FSModule backends 220, 225, and 230 which interface on one side to 

26 the SMB server 210 and on the other side to the backends 235, 240, and 245. The SMB server 

27 210 includes the server itself, the logging system and the control file that manages the SMB 

28 server. The design and implementation of the SMB server is based on an Internet-Draft, A 

29 Common Internet File System (CIFS) Protocol, 
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i 

1 http://msdn.microsoftxom/workshop/networking/cifs/default.asp. 

2 

3 

4 The backend, FFSModule 220, exposes ISash 250 which is a Common Object Model 

5 (COM) interface to communicate with the SMB server. The FFSModule receives requests 

6 from the SMB server through ISash, translates them to appropriate application programming 

7 interfaces (APIs) 255, 260, and 265 provided by client-API dynamic link libraries (dlls). The 

8 FFSModule then returns the pertinent information to the SMB server, 
9 

10 A COM interface, ISash 250, defines the intermediate programming interface between 

1 1 the SMB 210 and the FFSModule 220, 225, and 230 . The ISash interface comprises disk 
f42 type calls and is described in Table A. 

i 3 

%J4 FFSModule is a COM object. When the network command "net use devicename: 

R5 \\SMBservername\sharename" 270 is issued, the SMB 210 creates a new instance of 

6 FFSModule object 220 associated with the given sharename 275 and acquires the ISash 

« 17 interface pointer. The "SMBservername" 280 is the name of the SMB server, and "sharename" 

Iff 8 275 is a system name or a dataset name provided by a user. After SMB gets the ISash pointer, 

£719 it sends the first request to FFSModule to mount the sharename to a drive letter. Once a system 

-10 235 or a data set is mounted, it is simply treated as if it was a local native file system drive. 
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1 The following Table A is the list of requests that can come into SMB (a native file 

2 system protocol), the translated request (intermediate programming interface) to FFSModule 

3 from SMB, and the translated API calls made by FFSModule (foreign file system protocol) to 

4 obtain the necessary data from the file system, an MVS file system in this example: 
5 

6 

7 TABLE A 

8 Client to SMB Interface SMB to ISash Interface ISash to MVS 

9 SMB Call ISash Call MVS Call 

10 

1 1 SMB_COM_CHECK„DIRECTORY CheckDirectory CheckDirectory(BSTR InDirName, BYTE Is8p3, 

1 2 SashlDUnit uid, SashlDUnit pid, BSTR 

1 3 *OutDirName, BYTE *DoesExist) 
;44 Directory Li sting * 

fl5 DirectoryListing::getListing(*m_pHost, Qualifier); 

JjE6 new DirectoryListing::Cursor(**ppDirList, 

f]J7 CsrPattern); 

]ri 8 DirectoryListing::Cursor::setToFirst(); 
Jfj 9 Directory Listing: -.Cursor:: is Valid(); 

"■20 DirectoryLi sti ng: :Cursor : :element() ; 

A 1 unsigned char FFSFileItem::isDirectory() 

m 

}23 SMB_COM_CLOSE CloseFile CloseFile( SashFid Fid, BYTE Flags, SHORT 

fj24 Options ) 

25 The file object created at open time will be deleted. 

26 

27 SMB_COM_CREATE_DIRECTORY CreateDirectory CreateDirectory(BSTR NewDirectory, SashlDUnit 

28 TRANS2_CREATEJDIRECTORY uid, SashlDUnit pid ) 

29 Not supported. 
30 

31 SMB„COM_DELETE DeleteFile DeleteFiIe( BSTR FileName, SashFileAttributes 

32 FileAttributes, SashlDUnit uid, SashlDUnit pid ) 

33 FFSConnectedDrive * 

34 HostSystem::returnConnection(0,FALSE); 
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1 Result * 

2 FFSConnectedDrive::deleteFile(SlashName); 
3 

4 SMB_QUERY_FILE„BASIC JNFO FileAttributes File Attributes ( BSTR FileName, SHORT Options, 

5 SMB JNFO_STANDARD SashFile Attributes InAttributes, SashDate InDate, 

6 SMB JNFO_QUERY_EA JSIZE SashTime InTime, SashlDUnit uid, SashlDUnit 

7 SMB JNFO_QUERY_EAS_FROM_LIST pid, LONG *OutSize, 

8 SMBJNFO_QUERY„ALL_EAS SashFileAttributes *OutAttributes, 

9 SMB JNFO JS_NAME_ VALID SashDate *OutDate, SashTime *OutTime ) 
1 0 TRANS2 JJUERYJPATH ^INFORMATION 

1 1 SMB J2UERY„FILE_STANDARD_INFO 

1 2 SMB_QUERY_FILE„EA JNFO 

1 3 SMB J2UERY_FILE_NAME JNFO 
J4 SMB_COM_SETJNFORMATION 

TRANS2_SET_PATH_INFORMATION 

m 

^1 TRANS 2_SET JP ATH JNFORM ATTON FileDateTime FileDateTime( SashFid Fid, BYTE Flags, 

O 8 SMB JNFCLSTANDARD SashDate InDate, SashTime InTime, 

SMBJNFO_QUERYJEA_SIZE SashDate *OutDate, SashTime *OutTime ) 

; ;"20 Not called by SMB 

I? 1 

l%2 SMB_COM_FIND_CLOSE, FIND_CLOSE2 FindFileClose 

m 

f : fA SMB_COM_FIND FindFirstFiie FindFirstFiIe( BSTR SearchPattern, 

' 25 TRANS2_FIND_FIRST2 SashFileAttributes SearchAttributes, 

26 SMB_FIND_FILE_FULL_DIRECTORY_INFO SashlDUnit uid, SashlDUnit pid, 

27 SMBJFIND_FILE_BOTHjDIRECTORY JNFO BSTR *FileName, BSTR *ShortFileName, 

28 SashDate *CreationDate, 

29 SashTime *CreationTime, 

30 SashDate *LastAccessDate, 

3 1 SashTime *LastAccessTime, 

32 SashDate *LastModifyDate, 

33 SashTime *LastModifyTime, 

34 SashFileAttributes *FileAttributes, 

35 LONG *Size, FindHandle *hFind ) 



STL9-2000-0057US1 



■ 1 

2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 
13 
J4 

I 5 
W6 

J7 

138 SMB_COM_FIND 

"'.19 TRANS2_FINDJFIRST2 

,20 TRANS 2_FIND_NEXT2 
jjl 

I=€3 

= 25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 



DirectoryLi sting * 

DirectoryListing: :getListing(*m_pHost, Qualifier) 
new DirectoryListing: :Cursor(* *ppDirList, 
CsrPattern) 

DirectoryListing: :Cursor::setToFirst() 
DirectoryListing: : Cursor: : is Valid() 
DirectoryListi ng: :Cursor: :element() 
unsigned char FFSFileItem::isFile() 
const FFSFiie & FFSFileItem::asFile() 
const FFSFiie & FFSFileItem::asDirectory() 
FFSTimeStamp: :year() 
FFSTimeStamp: :month() 
FFSTimeStamp : : day () 
FFSTimeStamp: :hour() 
FFSTimeStamp: :minute() 
FFSTimeStamp: :second() 

FindNextFile FindNextFile( FindHandle hFind, BYTE Flags, 
BSTR *FiieName, BSTR *ShortFileName, 
SashDate *CreationDate, 
SashTime *CreationTime, 
SashDate *LastAccessDate, 
SashTime *LastAccessTime, 
SashDate *LastModifyDate, 
SashTime *LastModifyTime, 
SashFileAttributes *FileAttributes, 
LONG *Size ) 

DirectoryListing: :Cursor: :setToNext(); 
DirectoryListing: :Cursor: :isValid() 
DirectoryListing: : Cursor: :element().isFile() 
const FFSFiie & FFSFileItem::asFile() 
const FFSFiie & FFSFileItem::asDirectory() 
FFSTimeStamp; :year() 
FFSTimeStamp: :month() 
FFSTimeStamp: : day () 
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1 FFSTimeStamp::hour() 

2 FFSTimeStamp : : minute() 

3 FFSTimeStamp:: second () 
4 

5 SMB_COM„FLUSH FlushVolume Flush Volume( BYTE Flags, 

6 SashlDUnit uid, SashlDUnit pid) 

7 FFSFiIeFile::flush(); 
8 

9 Not applicable GetCustomlnterface GetCustomInterface( BSTR Path, IUnknown 

10 **pIUnknown ) 

1 1 This call is currently not used. It will be 

1 2 inplemented if necessary. 
13 

1 4 TRANS2_QUERY_FILE ^INFORMATION GetFilelnfo GetFileInfo( SashFid Fid, BSTR *FileName, 
15 BSTR 

116 *ShortFileName, 

J 7 BSTR*Path, 

rt 8 SashDate *CreationDate, 

y 9 SashTime *CreationTime, 

J 20 SashDate *LastAccessDate, 

X3L 1 SashTime *LastAccessTime, 

' \ 22 SashDate *LastModif yDate, 

y23 SashTime *LastModifyTime, 

G|>4 SashFileAttributes *FileAttributes, LONG *Size ) 

25 FFSFileFile::createdTime()->year() 

26 FFSFileFile::createdTime()->month() 

27 FFSFileFile::createdTime()->day() 

28 FFSFiIeFile::createdTime()->hour() 

29 FFSFileFile::createdTime()->minute() 

30 FFSFileFile::createdTime()->second() 

3 1 FFSFileFile::lastReadTime()->year() 

32 FFSFiIeFile::lastReadTime()->month() 

33 FFSFileFile::lastReadTime()->day() 

34 FFSFileFile::lastReadTime()->hour() 

35 FFSFileFile::lastReadTime()->minute() 
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1 FFSFi]eFile::lastReadTime()->second() 

2 FFSFileFile::lastModifiedTime()->year() 

3 FFSFiIeFiIe::IastModifiedTime()->month() 

4 FFSFileFile::lastModifiedTime()->day() 

5 FfSFileFile:;lastModifiedTime()->hour() 

6 FileFile::lastModifiedTime()->minute() 

7 FFSFileFile::lastModifiedTime()->second() 

8 FFSFiIeFile::length(); 
9 

10 SMB_QUERY_FS_SIZE_INFO GetFSFreeSpace GetFSFreeSpace( BSTR FSName, 

1 1 TRANS2_QUERY_FS_INFORMATION SashlDUnit uid, SashlDUnit pid, 

1 2 LONG *SectorsPerCluster, 

1 3 LONG *BytesPerSector, 

J 4 LONG *NumOfFreeClusters, 

J3 5 LONG *TotalNumberOfCIusters ) 

*M 6 This call is not applicable to MVS. Provide 

s=s 1 7 dummy data to satisfy SMB . 

O 8 *SectorsPerCluster = 256; 

y 9 *BytesPerSector = 256; 

a " 20 *NumOfFreeClusters = 1 26; 

M2 1 *TotalNumberOfCIusters = 4096; 

lM 

H>3 Not applicable Ink Init( BSTR Paths, BYTE *UseCompletePath ) 

r24 FFSControl::loadSystemXML(); 

25 HostS ystem * 

26 FFSControl::getSystem(ServerName); 
27 

28 SMB_COM_OPEN OpenFile OpenFile(BSTR FileName, SashFileAttributes 

29 SMB_COM_CREATE Attribs, SHORT Options, BYTE Flags, 

30 SMB_COM_NT_CREATE_ANDX SashlDUnit uid, SashlDUnit pid, SHORT 

31 ^Result, SashFid *Fid) 

32 DirectoryListing * 

33 DirectoryListing: :getListing(*m_pHost, Qualifier); 

34 new DirectoryListing: :Cursor(**ppDirList, 

35 CsrPattern); 
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1 DirectoryLi sting; -.Cursor: :setToFirst(); 



2 




DirectoryListing::Cursor::isValid(); 


3 




DirectoryListing: :Cursor : :element(); 


4 




unsigned char FFSFileItem::isDirectory() 


5 




new 


6 




FFSFileDirectory(SlashName,Attr f m_pCurrentHost) 


7 




new 


8 




FFSFileFile(SlashName,Attr J m_pCurrentHost); 


9 




FFSFileFile::fiush(); 


10 






1 1 


SMBJNFO_VOLUME QueryVolumelnfo 


QueryVolumeInfo( SashlDUnit uid, SashlDUnit 


12 


TRANS2_QUERYJFS_INFORMATION 


pid, BSTR *VolumeName, 


13 


SMB_QUERY_FS_VOLUME_INFO 


LONG *VolumeSerialNumber) 




SMB_COM„QUERYJNFORMATIONJ)ISK 


This call is not applicable to MVS. Provide 


3 5 




dummy data to satisfy SMB. 


oj7 


SMB_COM_READ Read 


Read( SashFid Fid, LONG Offset, LONG Count, 


Q8 


SMB_COM_LOCK_AND_READ 


SAFEARRAY **buf, LONG *BytesRead ) 


•§9 


SMB_COM_READ_RAW 


FFSFileFile::get(Offset,Count); 


J 20 


SMB_COM_READ„MPX 




5 1 


SMB„COM_READ_ANDX 




p2 






f^ 3 


SMB„COM_DELETEJDIRECTORY RemoveDirectory RemoveDirectory(BSTR Directory, 


H 24 




SashlDUnit uid, SashlDUnit pid) 


25 




Not supported. 


26 






27 


SMB_COMJRENAME Rename 


Rename( BSTR OldFileName, 


28 


SMB_COM_NT_RENAME 


SashFileAttributes FileAttributes 1 , 


29 




BSTR NewFileName, 


30 




SashFileAttributes FileAttributes2, 


31 




SashlDUnit uid, SashlDUnit pid, 


32 




BYTE Reserved) 


33 




FFSConnectedDrive * 


34 




HostSytem::returnConnection(0,FALSE); 


35 




DirectoryListing * 
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1 DirectoryListing::getListing(*m__pHost, 

2 Qualifier); 

3 new DirectoryListing::Cursor(**ppDirList, 

4 CsrPattern); 

5 DirectoryListing;:Cursor::setToFirst(); 

6 DirectoryListing::Cursor::isValid(); 

7 Directory Listing: -.Cursor: :element() ; 

8 unsigned char FFSFileltem: :isDirectory() 

9 Result * FFSConnectedDrive::renameFile 
1 0 (SlashOldNamcSlashNewName); 

11 



12 SMB_COM_SEEK 
13 
14 

5 6 

QJ8 SMB_COM_TREE_DIS CONNECT Unlnit 

V%9 TREEJDIS CONNECT 
;20 

m\ 

f ~22 SMB_COM_LOCKING_ANDX 

fi>3 SMB_COM_WRITE_ANDJJNLOCK 

M24 SMB_COM_TREE_DISCONNECT 



25 






26 


SMB_COM_WRITE Write 


Write( SashFid Fid, LONG Offset, LONG Count, 


27 


SMB_COM_WRITE_PRINT_FILE 


SAFEARRAY *buf, LONG *BytesWritten ) 


28 


SMB„COM_WRITE_AND_UNLOCK 


FFSFileFile::put((const char*)&RawBuffer, 


29 


Offset, 




30 


SMB_COM_READJRAW 


Count); FFSFile::seekToEnd(); 


31 


SMB_COM_WRITE_MPX 




32 


SMB_COM_WRITE_RAW 




33 


SMB_COM„WRITE__COMPLETE 




34 


SMB_COM_WRITE„MPX_SECONDARY 




35 


SMB_COM__WRITE_AND_CLOSE 
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Seek Seek( SashFid Fid, LONG Offset, BYTE Mode, 

LONG *NewOffset ) 
FFSFileFile::seek(CurrPos + Offset); 
FFSFileFile::tell(); 
FFSFileFile::seekToEnd(); 



UnlnitO 

Destroy all the file objects created. 
Destroy all the DirectoryListing created. 



UnlockFile UnlockFile( SashFid Fid ) 
Not called by SMB 



1 SMB_COM_WRITE_ANDX 

2 SMB_COM_WRITE_BULK 

3 SMB_COM_WRITE_BULK_DATA 
4 

5 

6 

7 

8 Referring now to Figure 3 and Figure 4, the flowcharts illustrate the operations 

9 preferred in carrying out the preferred embodiment of the present invention. In the flowcharts, 

10 the graphical conventions of a diamond for a test or decision and a rectangle for a process or 

1 1 function are used. These conventions are well understood by those skilled in the art, and the 

12 flowcharts are sufficient to enable one of ordinary skill to write code in any suitable computer 

13 programming language for an assembler, interpreter, or compiler. 
[| 4 

Kl 5 Referring first to Figure 3, after the start 310 of the process 300, a native request from a 

111 6 client on the workstation to the remote data processing system to open a foreign file in the 

rf7 foreign file is generated in process block 320. Responsive to the request, process block 330 

4-1 8 determines the native file system protocol; and process block 340 determines the foreign file 

CP 9 system protocol. Thereafter, process block 350 translates the native file system request to an 

iupO intermediate programming interface, wherein the intermediate programming interface is 

!l21 different from both the native file system protocol and the foreign file system protocol. Process 

M22 block 360 then translates the intermediate file system request to the foreign file system 

23 protocol. Thereafter, process block 370 issues the translated request to the foreign file system; 

24 and process block 380 returns to the client a response from the foreign file system responsive to 

25 the translated request. The process then ends at process block 390. 
26 

27 Referring now to Figure 4, process 400 is an expansion of the translation process steps 

28 340, 350, 360, and 370 of Figure 3. Decision block 410 determines if the native file system 

29 request is a common access function, an access function common to both the native file system 

30 protocol and the foreign file system protocol. If the native file system request is a common 
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1 access function, then process block 420 translates the common access function from the native 

2 file system protocol to the intermediate programming interface and then translates it from the 

3 intermediate system protocol to the foreign file system protocol. Thereafter, processing 

4 continues to process block 380 which returns the response to the client. 
5 

6 Returning now to decision block 410, if the native file system request is not a common 

7 access function, then decision block 440 determines if the native file system request is an 

8 extended native function, a native file system functions which have no equivalent function in 

9 the foreign file system protocol. If the native file system request is an extended native function, 

10 then process block 450 prepare a predetermined response to be sent to the client, preferably 

1 1 indicating the inability of the foreign file system to service the request. Thereafter, processing 
r4 2 continues to process block 380 which returns the response to the client. 

S3 

"14 Returning now to decision block 440, if the native file system request is not an 

Ol5 extended native function, then decision block 460 determines if the native file system request is 

'p6 an extended foreign function, a foreign file system function which has no equivalent function 

lJ 1 in the native file system protocol. If the native file system request is an extended foreign 

yfjl 8 function, then process block 470 passes through the extended foreign function to the foreign 

IT 19 file system in an untranslated form. Thereafter, processing continues to process block 380 

LJ20 which returns the response from the extended foreign function to the client. 
" 21 

22 Returning now to decision block 460, if the native file system request is not an 

23 extended foreign function, then process block 480 returns an error to the client as the request 

24 was neither a common, extended native, nor extended foreign function. 
25 

26 Using the foregoing specification, the invention may be implemented using standard 

27 programming and/or engineering techniques using computer programming software, firmware, 

28 hardware or any combination or sub-combination thereof. Any such resulting program(s), 

29 having computer readable program code means, may be embodied within one or more 
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1 computer usable media such as fixed (hard) drives, disk, diskettes, optical disks, magnetic tape, 

2 semiconductor memories such as Read-Only Memory (ROM), Programmable Read-Only 

3 Memory (PROM), etc., or any memory or transmitting device, thereby making a computer 

4 program product, i.e., an article of manufacture, according to the invention. The article of 

5 manufacture containing the computer programming code may be made and/or used by 

6 executing the code directly or indirectly from one medium, by copying the code from one 

7 medium to another medium, or by transmitting the code over a network. An apparatus for 

8 making, using, or selling the invention may be one or more processing systems including, but 

9 not limited to, central processing unit (CPU), memory, storage devices, communication links, 

10 communication devices, servers, input/output (I/O) devices, or any sub-components or 

1 1 individual parts of one or more processing systems, including software, firmware, hardware or 
: J2 any combination or sub-combination thereof, which embody the invention as set forth in the 
?0 3 claims. 

5 4 

1^5 User input may be received from the keyboard, mouse, pen, voice, touch screen, or any 

M 6 other means by which a human can input data to a computer, including through other programs 

17 such as application programs. 
Si 8 

Wl9 One skilled in the art of computer science will easily be able to combine the software 

q20 created as described with appropriate general purpose or special purpose computer hardware to 

* 21 create a computer system and/or computer sub-components embodying the invention and to 

22 create a computer system and/or computer sub-components for carrying out the method of the 

23 invention. Although the present invention has been particularly shown and described with 

24 reference to a preferred embodiment, it should be apparent that modifications and adaptations 

25 to that embodiment may occur to one skilled in the art without departing from the spirit or 

26 scope of the present invention as set forth in the following claims. 



STL9-2000-0057US1 



26 



